-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide better feedback to the user in case of invalid test classes #1286
Provide better feedback to the user in case of invalid test classes #1286
Conversation
Only one exception per invalid test class is now fired, rather than one per validation error, with all of the validation errors as part of its message. Example: org.junit.runners.InvalidTestClassError: Invalid test class 'InvalidTest': 1. Method staticAfterMethod() should not be static 2. Method staticBeforeMethod() should not be static Validation errors for the same test class now count only once in the failure count (Result#getFailureCount). Implementation: - ParentRunner#validate throws InvalidTestClassError in case of validation errors - ErrorReportingRunner fires the InvalidTestClassError above without unpacking the causes
} | ||
|
||
@Test | ||
public void givenInvalidTestClass_integrationTest() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please note the integration test here. I'm not sure if this is a good place for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine. Thanks!
I really like this. @junit-team/junit-committers any thoughts? |
👍 |
@@ -121,7 +121,7 @@ public void numbers(int x) { | |||
public void dataPointFieldsMustBeStatic() { | |||
assertThat( | |||
testResult(DataPointFieldsMustBeStatic.class), | |||
CoreMatchers.<PrintableResult>both(failureCountIs(2)) | |||
CoreMatchers.<PrintableResult>both(failureCountIs(1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verifying the failure count does not make sense anymore. I think it should be removed. @junit-team/junit-committers What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stefanbirkner only at line 123 or do you mean all of the tests asserting on result.failureCount?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've applied this to some other tests where it made sense. See d5fc61c.
Please take a look @stefanbirkner
Thanks
+1 |
Should be ready to be squashed and then merged. |
sb.append(String.format("Invalid test class '%s':", testClass.getName())); | ||
int i = 1; | ||
for (Throwable error : validationErrors) { | ||
sb.append("\n " + i++ + ". " + error.getMessage()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "\n " + (i++) + ". "
would be more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, thanks
Fixed conflicts with master |
@@ -0,0 +1,43 @@ | |||
package org.junit.runners; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this class should be in the org.junit.runners.model
package (with InitializationError
etc.).
@alb-i986 I found another minor thing. Sorry! |
@marcphilipp done |
Thanks, looks good to me! @junit-team/junit-committers Please take a look. :-) |
LGTM |
package org.junit.runners.model; | ||
|
||
import org.junit.Test; | ||
import org.junit.runners.model.InvalidTestClassError; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This import is unused now, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, thanks! Fixed now
public class InvalidTestClassError extends InitializationError { | ||
private static final long serialVersionUID = 1L; | ||
|
||
private final Class<?> testClass; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have to store testClass
since it's only used in the constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm ya right.
@alb-i986 Thanks for your hard work! Please add a description of this improvement to the draft of the release notes. |
@alb-i986 Merging this broke the build on JDK 5. Can you please take a look? https://junit.ci.cloudbees.com/job/JUnit/78/console |
Sorry about that, should be fixed by #1333 . I'm on a mobile phone now so i can't do any m How come Travis didn't catch that anyways? |
Done: Please let me know if you're happy enough. |
Great, thanks! |
Only one exception per invalid test class is now fired, rather than one per validation error, with all of the validation errors as part of its message.
Example:
Validation errors for the same test class now count only once in the failure count (Result#getFailureCount).
Implementation:
Follows how this change looks like in build tools.
Gradle 2.13
Before this change:
After this change:
maven-surefire-plugin 2.19.1 (on maven 3.3.9)
Before:
After:
Please note that maven-surefire-plugin 2.19.1 is already smart enough to compact the different validation errors for the same test class together, in the Results section. With the change I'm proposing here, build tools won't need this extra logic.